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Abstract 

To become practical for assurance, automated for- 
mal methods must be made more scalable, automatic, 
and cost-effective. Such an increase in scope, scale, au- 
tomation, and utility can be derived from an emphasis on 
a systematic separation of concerns during verification. 
SAL (Symbolic Analysis Laboratory ) attempts to address 
these issues. It is a framework for combining differ- 
ent tools to calculate properties of concurrent systems. 
The heart of SAL is a language, developed in collabora- 
tion with Stanford, Berkeley, and Verimagjor specifying 
concurrent systems in a compositional way. Our instan- 
tiation of the SAL framework augments PVS with tools 
for abstraction, invariant generation, program analysis 
(such as slicing), theorem proving, and model checking 
to separate concerns as well as calculate properties ( i.e., 
perform symbolic analysis) of concurrent systems. We 
describe the motivation, the language, the tools, their 
integration in SAL/PVS, and some preliminary experi- 
ence of their use. 


1 Introduction 

To become practical for debugging, assurance, and 
certification, formal methods must be made more cost- 
effective. Incremental improvements to individual ver- 
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ification techniques will not suffice. It is our basic 
premise that a significant advance in the effectiveness 
and automation of verification of concurrent systems is 
possible by engineering a systematic separation of con- 
cerns through a truly integrated combination of static 
analysis, model checking, and theorem proving tech- 
niques. A key idea is to change the perception (and im- 
plementation) of model checkers and theorem provers 
from tools that perform verifications to ones that calcu- 
late properties such as slices, abstractions and invariants. 
In tins way, big problems are cut down to manageable 
size, and properties of big systems emerge from those of 
reduced subsystems obtained by slicing, abstraction, and 
composition. By iterating through several such steps, it 
becomes possible to incrementally accumulate proper- 
ties that eventually enable computation of a substantial 
new property — which in turn enables accumulation of 
further properties. By interacting at the level of proper- 
ties and abstractions, multiple analysis tools can be used 
to derive properties that are beyond the capabilities of 
any individual tool. 

SAL (Symbolic Analysis Laboratory) addresses 
these issues. It is a framework for combining dif- 
ferent tools for abstraction, program analysis, theorem 
proving, and model checking toward the calculation of 
properties (symbolic analysis) of concurrent systems ex- 
pressed as transition systems. The heart of SAL is an 
intermediate language, developed in collaboration with 
Stanford, Berkeley, and Verimag for specifying concur- 
rent systems in a compositional way. This language will 
serve as the target for translators that extract the tran- 
sition system description for popular programming lan- 
guages such as Esterel, Java, or Verilog. The intermedi- 
ate language also serves as a common description from 
which different analysis tools can be driven by translat- 
ing file intermediate language to the input format for the 
tools and translating the output of these tools back to the 
SAL intermediate language. 

This paper is structured as follows. In Section 2 we 



describe the motivation and rationale behind the design 
of the SAL language and give an overview of its main 
features. The main part. Section 3, describes SAL com- 
ponents including slicing, invariant generation, abstrac- 
tion, model checking, simulation, and theorem proving 
together with their integration into the SAL toolset. Sec- 
tion 4 concludes with some remarks. 

2 The SAL Common Intermediate Lan- 
guage 

Mechanized formal analysis starts from a description 
of the problem of interest expressed in the notation of 
the tool to be employed. Construction of this descrip- 
tion often entails considerable work: first to recast the 
system specification from its native expression in C, Es- 
terel, Java, SCR, UML, Verilog, or whatever, into the 
notation of the tool concerned, then to extract the part 
that is relevant to the analysis at hand, and finally to re- 
duce it to a form that the tool can handle. If a second tool 
is to be employed for a different analysis, then a second 
description of the problem must be prepared, with con- 
siderable duplication of effort. With m source languages 
and n tools, we need m*n translators. This situation nat- 
urally suggests use of a common intermediate language, 
where the numbers of tools required could be reduced to 
m + n translators. 

The intermediate language must serve as a medium 
for representing the state transition semantics of a sys- 
tem described in a source language such as Java or Es- 
terel. It must also serve as a common representation 
for driving a number of back-end tools such as theorem 
provers and model checkers. A useful intermediate lan- 
guage for describing concurrent systems must attempt to 
preserve both the structure and meaning of the original 
specification while supporting a modular analysis of the 
transition system. 

For these reasons, the SAL intermediate language is a 
rather rich language. In the sequel, we give an overview 
of the main features of the SAL type language, the ex- 
pression language, the module language, and the con- 
text language. For a precise definition and semantics of 
the SAL language, including comparisons to related lan- 
guages for expressing concurrent systems, see [31], 

The type system of SAL supports basic types such 
as booleans, scalars, integers and integer subranges, 
records, arrays, and abstract datatypes. Expressions 
are strongly typed. The expressions consist of con- 
stants, variables, applications of Boolean, arithmetic, 
and bit-vector operations (bit-vectors are just arrays of 
Booleans), and array and record selection and updates. 
Conditional expressions are also part of the expression 


mutex : CONTEXT = 

BEGIN 

PC: TYPE = {trying, criti- 
cal, sleeping} 

mutex [tval : boolean] : MODULE = 
BEGIN 

INPUT pc2 : PC, x2 : boolean 
OUTPUT pci: PC, xl : boolean 

INITIALIZATION 

TRUE --> pci = sleeping; 
xl = tval 

TRANSITION 

pci = sleeping 

--> pci' = trying; 

xl' = (x2=tval) 

[] 

pci = trying AND 
(pc2=sleeping OR xl= (x2/=tval) ) 
--> pci' = critical 

[] 

pci = critical 

--> pci' = sleeping; 
xl' = (x2=tval) 

END 

system: MODULE = 

HIDE xl , x2 
(mutex [FALSE] 

| | RENAME pc2 TO pci, 
x2 TO xl, 
pci TO pc2, 
xl TO x2 
mutex [TRUE] ) 

mutualExclusion : THEOREM 
system | - 

AG (NOT (pcl=critical 

AND pc2=critical ) ) 

eventual lyl : LEMMA 

system |- EF (pcl=critical ) 
eventually2 : LEMMA 

system |- EF (pc2=critical ) 

END 


Figure 1. Mutual Exclusion 



language and user-defined functions may also be intro- 
duced. 

A module is a self-contained specification of a tran- 
sition system in SAL. Usually, several modules ate col- 
lected in a context. Contexts also include type and con- 
stant declarations. A transition system module consists 
of a state type, an initialization condition on tins state 
type, and a binary transition relation of a specific form 
on the state type. The state type is defined by four pah- 
wise disjoint sets of input, output, global, and local vari- 
ables. The input and global variables are the observed 
variables of a module and the output, global, and local 
variables are the controlled variables of the module. It 
is good pragmatics to name a module. This name can be 
used to index the local variables so that they need not be 
renamed during composition. Also, the properties of the 
module can be indexed on the name for quick lookup. 

Consider, for example, the SAL specification of a 
variant of Peterson’s mutual exclusion algorithm in Fig- 
ure 1. Fie re the state of the module consists of the 
controlled variables corresponding to its own program 
counter pci and boolean variable xl, and the observed 
variables are the corresponding pc 2 and x2 of the other 
process. 

The transitions of a module can be specified variable- 
wise by means of definitions or transition-wise by 
guarded commands. Ffenceforth, primed variables X ' 
denote next-state variables. A definition is of the form 
X = f ( Y , Z ) . Both the initializations and transitions 
can also be specified as guarded assignments. Each 
guarded command consists of a guarded formula and an 
assignment part. The guard is a boolean expression in 
the current controlled (local, global, and output) vari- 
ables and current-state and next-state input variables. 
The assignment part is a list of equalities between a left- 
hand side next-state variable and a right hand side ex- 
pression in both current-state and next-state variables. 

Parametric modules allow the use of logical (state- 
independent) and type parameterization in the definition 
of modules. Module mutex in Figure 1, for example, is 
parametric in the Boolean tval. Furthermore, mod- 
ules in SAL can be combined by either synchronous 
composition | | , or asynchronous composition [] . Two 
instances of the mutex module, for example, are con- 
joined synchronously to form a module called system 
in Figure 1. This combination also uses hiding and re- 
naming. Output and global variables can be made local 
by the HIDE construct. In order to avoid name clashes, 
variables in a module can be renamed using the RENAME 
construct. 

Besides declaring new types, constants, or modules, 
SAL also includes constructs for stating module prop- 
erties and abstractions between modules. CTL formulas 


are used, for example, in Figure 1 to state safety and live- 
ness properties about the combined module system. 

The form of composition in SAL supports a com- 
positional analysis in the sense that any module prop- 
erties expressed in linear-time temporal logic or in the 
more expressive universal fragment of CTL* are pre- 
served through composition. A similar claim holds for 
asynchronous composition with respect to stuttering in- 
variant properties where a stuttering step is one where 
the local and output variables of the module remain un- 
changed. 

Because SAL is an environment where theorem prov- 
ing as well as model checking is available, absence of 
causal loops in synchronous systems is ensured by gen- 
erating proof obligations, rather than by more restrictive 
syntactic methods as in other languages. Consider the 
following definitions: 

X = IF A THEN NOT Y ELSE C END IF 

Y = IF A THEN B ELSE X END IF 

This pair of definitions is acceptable in SAL because we 
can prove that X is causally dependent on Y only when 
A is true, and vice-versa only when it is false — hence 
there is no causal loop. In general, causality checking 
generates proof obligations asserting that the conditions 
that can trigger a causal loop are unreachable. 

3 SAL Components 

SAL is built around a blackboard architecture cen- 
tered around the SAL intermediate language. Different 
backend tools operate on system descriptions in the in- 
termediate language to generate properties and abstrac- 
tions. The core of the SAL toolset includes the usual 
infrastructure for parsing and type-checking. It also al- 
lows integration of translators and specialized compo- 
nents for computing and verifying properties of transi- 
tion systems. These components are loosely coupled 
and communicate through well-defined interfaces. An 
invariant generator may expect, for example, various ap- 
plication specific flags and a SAL base module, and it 
generates a corresponding assertion in the context lan- 
guage together with a justification of the invariant. The 
SAL toolset keeps track of the dependencies between 
generated entities, and provides capabilities similar to 
proof-chain analysis in theorem proving systems like 
PVS. 

The main ingredients of the SAL toolset are special- 
ized components for computing and verifying properties 
of transition systems. Currently, we have integrated var- 
ious components providing basic capabilities for analyz- 
ing SAL specifications, including 



• Validation based on theorem proving, model check- 
ing, and animation; 

• Abstraction and invariant generation; 

• Generation of counterexamples; 

• Slicing. 

We describe these components hi more detail below. 

3.1 Backend translations 

We have developed translators from the SAL inter- 
mediate language to PVS, SMV, and Java for validat- 
ing SAL specifications by means of theorem proving 
(in PVS), model checking (in SMV), and animation (in 
Java). These compilers implement shallow structural 
embeddings [26] of the SAL language; that is, SAL 
types and expressions are given a semantics with re- 
spect to a model defined by the logic of the target lan- 
guage. The compilers performs a limited set of semantic 
checks. These checks mainly concern the use of state 
variables. More complex checks, as for example type 
checking, are left to the verification tools. 

3.1.1 Theorem Proving: SAL to PVS 

PVS is a specification and verification environment 
based on higher-order logic [27]. SAL contexts con- 
taining definitions of types, constants, and modules, are 
translated into PVS theories. This translation yields a se- 
mantics for SAL transition systems. Modules are trans- 
lated as parametric theories containing a record type to 
represent the state type, a predicate over states to rep- 
resent the initialization condition, and a relation over 
states to represent the transition relation. Figure 2 de- 
scribes a typical translation of a SAL module in PVS. 
Notice that initializations as well as transitions may be 
nondeterm inistic. 

Compositions of modules are embedded as logical 
operations on the transition relations of the correspond- 
ing modules: disjunction for the case of asynchronous 
composition, conjunction for the case of synchronous 
composition. Hiding and renaming operations are mod- 
eled as morphisms on the state types of the modules. 
Logical properties are encoded via the temporal logic of 
the PVS specification language. 

3.1.2 Model Checking: SAL to SMV 

SMV is a popular model checker with its own system 
description language [25], SAL modules are mapped to 
SMV modules. Type and constant definitions appearing 


module [para : Parameters] : THEORY 
BEGIN 

State : TYPE = [# 

input : InputVars, 
output : OutputVars , 
local : LocalVars 

#] 

state, next : VAR State 

initialization (state) :boolean = 
(guard_init_l AND 
output (state) = ... AND 
local (state) = . . . ) 

OR . . . OR (guard_init_n AND . . . ) 

transitions ( state , next) : boolean = 
(guard_trans_l AND 
output (next) = 

output ( state) WITH [...] 
local (next) = 

local (state) WITH [... ]) 

OR ... OR 

(guard_trans_m AND . . . ) 

OR 

(NOT guard_trans_l AND . . . AND 
NOT guard_trans_m AND 
output (next) = output ( state) 
local (next) = local ( state ) ) 

Figure 2. A SAL module in PVS 

in SAL contexts are directly expanded in the SMV spec- 
ifications. Output and local variables are translated to 
variables in SMV. Input variables are encoded as param- 
eters of SMV modules. 

The nondeterministic assignment of SMV is used to 
capture the arbitrary choice of an enabled SAL transi- 
tion. Roughly speaking, two extra variables are intro- 
duced. The hist is assigned nondeterministically with a 
value representing a SAL transition. The guard of the 
transition represented by this variable is the first guard 
to be evaluated. The second variable loops over all tran- 
sitions starting from the chosen one until it finds a tran- 
sition which is enabled. This mechanism assures that 
every transition satisfying the guard has an equal chance 
to being hied in the hrst place. Composition of SAL 
modules and logical properties are directly translated via 
the specification language of SMV. 

3.1.3 Animation: SAL to Java 

Animation of SAL specifications is possible via compi- 
lation to Java. However, not all the features of the SAL 



language are supported by the compiler. In particular; 
the expression language that is supported is limited to 
that of Java. For example, only integers and booleans are 
accepted as basic types. Elements of enumeration types 
are translated as constants and record types are repre- 
sented by classes. 

The state type of a SAL module is represented by 
a class containing fields for the input, output, and lo- 
cal variables. In order to simulate the nondeterminism 
of the initialization conditions, we have implemented a 
random function that arbitrary chooses one of the initial- 
ization transition satisfying the guard. 

Each transition is translated as a Java thread class. 
At execution time, all the threads share the same state 
object. We assume that the Java virtual Machine is non- 
deterministic with respect to execution of threads. The 
main function of the Java translation creates one state 
object and passes the object as an argument to the thread 
object constructors. It then starts all the threads. Safety 
properties are encoded by using the exception mecha- 
nism of Java, and are checked at run time. 

3.1.4 Case Study: Flight Guidance System 

Mode confusion is a concern in aviation safety. It oc- 
curs when pilots get confused about the actual states of 
the flight deck automation. NASA Langley conducts 
research to formally characterize mode confusion situ- 
ations in avionics systems, hr particular, a prototype 
of a Flight Guidance System (FGS) has been selected 
a case study for the application of formal techniques to 
identify mode confusion problems. FGS has been spec- 
ified in various formalisms (see [23] for a comprehen- 
sive list of related work). Based on work by Luttgen 
and Carreno, we have developed a complete specifica- 
tion of FGS in SAL. The specification has been auto- 
matically translated to SMV and PVS, where it has been 
analyzed. We did not experience any significant over- 
head in model checking translated SAL models com- 
pared to hand-coded SMV models. This case study is 
available at http : / /www . lease . edu . /~munoz / 
sources . html. 

3.2 Invariant Generation 

An invariant of a transition system is an assertion — 
a predicate on the state — that holds of every reachable 
state of the transition system. An inductive invariant is 
a assertion that holds of the initial states and is preserved 
by each transition of the transition system. An inductive 
invariant is also an invariant but not every invariant is 
inductive. 

Let SP(T, <j>) denote the formula that represents the 
set of all states that can be reached from any state in <j> 


via a single transition of the system T, and © denote the 
formula that denotes the initial states. A formula <p is 
an inductive invariant for the transition system T if (i) 

© — y 4>\ (ii) sp(T , <p) — r 0. 

We recall that for a given transition system T and 
a set of states described by formula (j> , the notation 
SP(T, <j>) denotes the formula that characterizes all 
states reachable from states <i> using exactly one transi- 
tion from T. If 0 denotes the initial state, then it follows 
from the definition of invariants that any fixed-point of 
the operator F(<j>) = SP(T, <j>) V 0 is an invariant. 

Notice that the computation of strongest postcondi- 
tions introduces existentially quantified formulas. Due 
to novel theorem proving techniques in PVS2.3 that are 
based on the combination of a set of ground decision 
procedures and quantifier elimination we are able to ef- 
fectively reason about these formulas in many interest- 
ing cases. 

It is a simple observation that not only is the greatest 
fixed point of the above operator an invariant, but ev- 
ery intermediate (pi generated in an iterated computation 
procedure of greatest fixed point also is an invariant. 

<po : true 

<Pi+ 1 : SP (T,&)V© 

A consequence of the above observation is that we do 
not need to detect when we have reached a fixed point in 
order to output an invariant. 

As a teclmical point about implementation of the 
above greatest fixed point computation in SAL, we men- 
tion that we break up the (possibly infinite) state space 
of the system into finitely many (disjoint) control states. 
Thereafter, rather than working with the global invari- 
ants cpi, we work with local invariants that hold at par- 
ticular' control states. The iterative greatest fixed point 
computation can now be seen as a method of generating 
invariants based on affirmation and propagation [6], 

Note that rather than computing the greatest fixed 
point, if we performed the least fixed point computation, 
we would get the strongest invariant for any given sys- 
tem. The problem with least fixed points is that then 
computation does not converge as easily as those of 
greatest fixed points. Unlike greatest fixed points, the 
intermediate predicates in the computation of the least 
fixed point are not invariants. We are currently investi- 
gating approaches based on widening to compute invari- 
ants in a convergent manner using least fixed points [8], 

Hie techniques described so far are noncomposi- 
tional since they examine all the transitions of the given 
system. We use a novel composition rule defined in [29] 
allowing local invariants of each of the modules to be 
composed into global invariants for the whole system. 



This composition rule allows us to generate stronger in- 
variants than the invariants generated by the techniques 
described hi [6,7], The generated invariants allows us to 
obtain boolean abstractions of the analyzed system using 
the incremental analysis techniques presented in [29], 

3.3 Slicing 

Program analyses like slicing can help remove code 
irrelevant to the property under consideration from the 
input transition system which may result in a reduced 
state-space, thus easing the computational needs of sub- 
sequent fonnal analysis effoits. Our slicing tool [18] 
accepts an input transition system which may be syn- 
chronously or asynchronously composed of multiple 
modules written in SAL and the property under verifica- 
tion. The property under verification is converted into a 
slicing criterion and the input transition system is sliced 
with respect to this slicing criterion. The slicing crite- 
rion is merely a set of local/output variables of a subset 
of the modules in the input SAL program that are not 
relevant to the property. The output of the slicing al- 
gorithm is another SAL program similarly composed of 
modules wherein irrelevant code manipulating irrelevant 
variables from each module has been sliced out. For ev- 
ery input module there will be an output module, empty 
or otherwise. In a nutshell the slicing algorithm does 
a dependency analysis of each module and computes 
backward transitive closure of the dependencies. This 
transitive closure would take into consideration only a 
subset of all transitions in the module. We call these 
transitions observable and the remaining transitions are 
called t or silent transitions. We replace silent transi- 
tions with skips. 

We are currently investigating reduction techniques 
that are simpler than slicing and also ones that are more 
aggressive. One example is the cone-of-mfluence re- 
duction where the slicing criterion is a set of variables 
V, and the reduction computes a transition system that 
includes all the variables in the transitive closure of V 
given by the dependencies between variables [21], In 
comparison with slicing, the cone-of-mfluence reduc- 
tion is insensitive to control and is therefore easier to 
compute but generally not as efficient at pruning irrele- 
vance. Slicing preserves program behavior with respect 
to the slicing criterion. One could obtain a more dra- 
matic reduction by admitting slices that admitted more 
behaviors by introducing nondeterminism. Such aggres- 
sive slicing would be needed for example to abstract 
away from the internal behavior of a transition system 
within its critical section for the purpose of verifying 
mutual exclusion. Slicing for concurrent systems with 
respect to temporal properties has been investigated by 


Dwyer and Hatcliff [16], 

3.4 Connecting InVeSt with SAL 

So far we have described specialized SAL compo- 
nents that provide core features for the analysis of con- 
current systems, but we have also integrated the stand- 
alone InVeSt [5] into the SAL framework. Besides com- 
positional techniques for constructing abstraction and 
features for generating counterexamples from failed ver- 
ification attempts, InVeSt introduces alternative methods 
for invariant generation to SAL. InVeSt not only serves 
as a backend tool for SAL but also has been connected 
to the IF laboratory [10], Aldebaran [9], TGV [17] and 
Kronos [15]. 

The salient feature of InVeSt is that it combines the 
algorithmic with the deductive approaches to program 
verification in two different ways. First, it integrates the 
principles underlying the algorithmic (e.g. [11,28]) and 
the deductive methods (e.g. [24]) in the sense that it uses 
fixed point calculation as in the algorithmic approach but 
also the reduction of the invariance problem to a set of 
first-order formulas as in the deductive approach. Sec- 
ond, it integrates the theorem prover PVS [27] with the 
model checker SMV [25] through the automatic com- 
putation of finite abstractions. That is, it provides the 
ability to automatically compute finite abstractions of 
infinite state systems which are then analyzed by SMV 
or, alternatively, by the model checker of PVS. Further- 
more, InVeSt supports the proof of invariance proper- 
ties using the method based on induction and auxiliary 
invariants (e.g. [24]) as well as a method based on ab- 
straction techniques [2, 12-14,21,22], InVeSt uses PVS 
as a backend tool and depends heavily on its theorem 
proving capabilities for deciding the myriad verification 
conditions. 

3.4.1 Abstraction 

InVeSt provides also a capability that computes an ab- 
stract system from a given concrete system and an ab- 
straction function. The method underlying this tech- 
nique is presented in [4], The main features of this 
method is that it is automatic and compositional. It com- 
putes an abstract system S a = 5* || • • • || .S'", for a 
given system S = S 1 || • • • || S n and abstraction func- 
tion a, such that S simulates S a is guaranteed by the 
construction. Hence, by known preservation results, if 
S a satisfies an invariant <p then S satisfies the invari- 
ant a -1 (p). Since the produced abstract system is not 
given by a graph but in a programming language, one 
still can apply all the known methods for avoiding the 
state explosion problem while analyzing S a . Moreover, 



it generates ail abstract system which has the same struc- 
ture as the concrete one. This gives the ability to apply 
further abstractions and techniques to reduce the state 
explosion problem and facilitates the debugging of the 
concrete system. The computed abstract system is op- 
tionally represented in the specification language of PVS 
or in that of SMV. 

The basic idea behind our method of computing ab- 
stractions is simple. In order to construct an abstrac- 
tion of S, we construct for each concrete transition r c 
an abstract transition r a . To construct r a we proceed by 
elimination starting from the universal relation, which 
relates every abstract state to every abstract state, and 
eliminate pairs of abstract states in a conservative way, 
that is, it is guaranteed that after elimination of a pah the 
obtained transition is still an abstraction of r c . To check 
whether a pair (o, o') of abstract states can be eliminated 
we have to check that the concrete transition t c does not 
lead from any state c with a(c) = a to any state c' with 
a(c') = o'. This amounts to proving a Hoare triple. The 
elimination method is in general too complex. There- 
fore, we combine it with three teclmiques that allow 
many fewer Hoare triples to be checked. These tech- 
niques are based on partitioning the set of abstract vari- 
ables, using substitutions, and a new preservation result 
which allows to use the invariant to be proved during the 
construction process of the abstract system. 

We implemented our' method using the theorem 
prover PVS [27] to check tire Hoare triples generated by 
the elimination method. The first-order formulas corre- 
sponding to these Hoare triples are constructed automat- 
ically and a strategy that is given by the user is applied. 
In [1] we developed also a general analysis methodol- 
ogy for heterogeneous infinite-state models, extended 
automata operating on variables which may range over 
several different domains, based on combining abstrac- 
tion and symbolic reachability analysis. 

3.4.2 Generation of Invariants 

There are two different way to generate invariants in 
InVeSt. First, we use calculation of pre-fixed points 
by applying the body of the backward procedure a fi- 
nite number of times and use teclmiques for the auto- 
matic generation of invariants (cf. [3]) to support the 
search for auxiliary invariants. The tool provides strate- 
gies which allow derivation of local invariants, that is, 
predicates attached to control locations and which are 
satisfied whenever the computation reaches the corre- 
sponding control point. hiVeSt includes strategies for 
deriving local invariants for sequential systems as well 
as a composition principle that allows combination of 
invariants generated for sequential systems to obtain in- 


variants of a composed system. Consider a composed 
system S\ || .Sp and control locations p and 1 2 of .S) 
and S2 , respectively. Suppose that we generated the lo- 
cal invariants P] and P 2 at /, and p, respectively. Let us 
call P{ interference independent, if does not contain a 
free variable that is written by Sj with j f i. Then, de- 
pending on whether Pj is interference independent we 
compose the local invariants P, and P 2 to obtain a lo- 
cal invariant at (p , ) as follows: if P t is interference 

independent, then we can affirm that P 2 is an invariant 
at (/] , p) and if both Pi and P 2 are interference depen- 
dent, then Pj VP 2 is an invariant at (Zi , p). This compo- 
sition principle proved to be useful in the examples we 
considered. However, examples showed that predicates 
obtained by this composition principle can become very 
large. Therefore, we also consider the alternative option 
where local invar iants are not composed until they are 
needed in a verification condition. Tims, we assign to 
each component of the system two lists of local invari- 
ants. The first corresponds to interference independent 
local invariants and the second to interference dependent 
ones. Then, when a verification condition is considered, 
we use heuristics to determine which local invariants are 
useful when discharging the verification condition. A 
useful heuristic concerns the case when the verification 
condition is of the form (pc(l) = p Apc(2) = p) => <fi, 
where pel 1 ) = l\ A pc(2) = / 2 asserts that computation 
is at the local control locations 1 1 and p. In this case, we 
combine the local invariants associated to p and p and 
add the result to the left hand side of the implication. 

Second, we use abstraction generating invariants at 
the concrete level: Let <S ai the result of the abstrac- 
tion of a concrete system S, the set of reachable states 
denoted by Reach(S ai ) is an invariant of S ai (the 
strongest one including the initial configurations in fact). 
We developed a method that extract the fonnula which 
characterizes the reachable states from the BDD. Hence, 
op 1 ( Reach(S ai )) is an invariant of the concrete model 
S. This invariant can be used to strengthen ip and show 
that it is an invariant of S. 

3.4.3 Analysis of Counterexamples 

The generation of the abstract system is completely au- 
tomatic and compositional as we consider transition by 
transition. Thus, for each concrete transition we obtain 
an abstract transition (which might be nondetenninistic). 
This is a very important property of our method, since it 
enables the debugging of the concrete system or alter- 
natively enhancing the abstraction function. Indeed, the 
constructed abstract system may not satisfy the desired 
property, for three possible reasons: 

1 . The concrete system does not satisfy the invariant. 



2. The abstraction function is not suitable for proving 
the invariant, or 

3. The proof strategies provided are too weak. 

Now, a model checker such as SMV provides a trace as 
a counterexample, if the abstract system does not satisfy 
the abstract invariant. Since we have a clear correspon- 
dence between abstract and concrete transitions, we can 
examine the trace and find out which of the three rea- 
sons listed above is the case. In particular if the concrete 
system does not satisfy the invariant then we can trans- 
form the trace given by SMV to a concrete trace, thus 
generating a concrete counterexample. 

3.5 Predicate/Boolean Abstraction 

In addition to the InVeSt abstraction mechanisms, we 
implemented boolean abstraction of SAL specifications. 
We use file boolean abstraction scheme defined in [19] 
that uses predicates over concrete variables as abstract 
variables to abstract infinite or large state systems into 
finite state systems analyzable by model checking. The 
advantage of using boolean abstractions can be summa- 
rized as follows: 

• Any abstraction to a finite state system can be ex- 
pressed as a boolean abstraction. 

• The abstract transition relation can be repre- 
sented symbolically using Binary Decision Dia- 
gram (BDDs). Tlius, efficient symbolic model 
checking [25] can be effectively applied. 

• We have defined in [30] an efficient algorithm for 
the construction of boolean abstractions. We also 
designed an efficient refinement technique that al- 
lows us to refine automatically an already con- 
structed abstraction until the property of interest is 
proved or a counter-example is generated. 

• Abstraction followed by model checking and suc- 
cessive refinement is an efficient and more pow- 
erful alternative to invariant generation techniques 
such as the ones presented in [6,7], 

3.5.1 Automatic Construction of Boolean Abstrac- 
tions 

The automatic abstraction module takes as input a SAL 
basemodule and a set of predicates defining the boolean 
abstraction. Using the algorithm in [30] we automati- 
cally construct the corresponding abstract transition sys- 
tem. This process relies heavily on the PVS decision 
procedures. 


INPUT x: integer 
OUTPUT y, z: integer 


INITIALIZATION 

TRUE --> INIT(x) = 0; 

INIT(y) = 0; 
INIT(z) = y; 


TRANSITION 

NOT(x >0) --> y' = y + 1 
[] z > 0 --> z' = y - I# y' = 0 


Figure 3. Concrete Module. 


Figure 3 and 4 display a simple SAL module and its 
abstraction where the boolean variables Bl, B2 and B3 
correspond to the predicates x > 0, y > 0, and 3 > 0. 
Notice that the assignment to B3 is nondeterministically 
chosen from the set { T RUE , FALSE}. 


INPUT Bl: boolean 
OUTPUT B2,B3: boolean 


INITIALIZATION 

TRUE --> INIT(Bl) 
INIT (B2 ) 
INIT (B3 ) 


FALSE ; 
FALSE ; 
FALSE ; 


TRANSITION 

NOT (Bl ) --> B2'=F 

[] B3 --> B2 ' =T , B3 ' = { TRUE, FALSE } 


Figure 4. Abstract Module. 


3.5.2 Explicit Model Checking 

Finite-state SAL modules can be translated to SMV for 
model checking as explained above. However, model 
checkers usually do not allow to access their internal 
data structures where intermediate computation steps of 
the model-checking process can be exploited. For tins 
reason, we implemented an efficient explicit-state model 
checker for SAL systems obtained by boolean abstrac- 
tion. The abstract SAL description is translated into 
an executable Lisp code that performs the explicit state 
model checking procedure allowing us to explore about 



twenty thousand states a second. This procedure builds 
an abstract state graph that can be exploited for further 
analysis. Furthermore, additional abstractions can be 
applied on the fly while the abstract state graph is be- 
ing built. 

3.5.3 Automatic Refinement of Abstractions 

When model checking fails to establish the property of 
interest, we use the results developed in [29, 30] to de- 
cide whether the constructed abstraction is too coarse 
and needs to be refined, or that the property is violated 
in the concrete system and that the ge nerated counter- 
example corresponds indeed to an execution of the con- 
crete system violating the property. This is done by ex- 
amining the generated abstract state graph. The refine- 
ment technique computes the precondition to a transition 
where nondeterministic assignments occur. The precon- 
ditions corresponding to file cases where the variables 
get either TRUE or FALSE define two predicates that are 
used as new abstract variables. The following transition 
from the example 

B3 --> B2 ' =TRUE , B3 ' = {TRUE, FALSE} 

can be automatically refined to 

B3 B2 ' =TRUE , B3 ' =B4 , 

B4 ' =FALSE , B5 ' = FALSE 

where B4 and B5 correspond to the predicates y=l and 
y>l, respectively. 

4 Conclusions 

SAL is a tool that combines techniques from static 
analysis, model checking, and theorem proving in a truly 
integrated environment. Currently, its core is realized as 
an extension of the PVS system and has a well-defined 
interface for coupling specialized analysis tools. So 
far, we have been focusing on developing and connect- 
ing back-end tools for validating SAL specifications by 
means of animation, theor em proving, and model check- 
ing, and also for computing abstractions, slices, and in- 
variants of SAL modules. There are as yet no automated 
translators into the SAL language. Primary candidates 
are translators for source languages such as Java, Ver- 
ilog, Esterel, Statecharts, or SDL. Since SAL is an open 
system with well-defined interfaces, however, we hope 
others will write those if the rest of the system proves 
effective. 

We are currently completing the implementation of 
the SAL prototype which includes a parser, typechecker, 
a slicer, an invariant generator, the connection to InVeSt, 


and translators to SMV and PVS. We expect to release 
the prototype SAL system in mid-2000. 

Although our experience with file combined power of 
several forms of mechanized formal analysis in the SAL 
system is still rather limited, we predict that proofs and 
refutations of concurrent systems that currently require 
significant human effort will soon become routine cal- 
culations. 
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